\documentclass{article}

\title{RSO - koncepcja projektu}
\author{buli}

\usepackage{graphicx}
\usepackage{polski}
\usepackage[utf8]{inputenc}

\usepackage{anysize}
\marginsize{1cm}{1cm}{1cm}{1cm}



\begin{document}

\maketitle 

\section{O dokumencie}

Nie upieram się przy tej koncepcji, ale może przynajmniej jej elementy można będzie wykorzystać w tej uzgodnionej wspólnie. Spróbuję natomiast pokazać, że {\bf spełnia ona wymagania} projektu i co ważniejsze, jest {\bf wykonalna} w skończonym czasie, tzn. mechanizmy działania są możliwie  proste.

\section{Definicja problemu}

Tematem, jeśli dobrze pamiętam, jest ``Rozproszona grafowa baza danych''. Zgodnie z definicjami z Wikipedii:
\begin{enumerate}
	\item {\bf Rozproszona baza danych} - baza danych istniejąca fizycznie na dwóch lub większej liczbie komputerów, traktowana jednak jak jedna logiczna całość (...). Rozproszone bazy danych można określić jako zespół baz danych znajdujących się na różnych komputerach połączonych ze sobą w taki sposób, że użytkownik nie wie, iż dane, z którymi pracuje, pochodzą z różnych baz i komputerów
	\item {\bf System rozproszony} posiada następujące cechy: dzielenie zasobów, otwartość, współbieżność, skalowalność, tolerowanie awarii, przezroczystość
\end{enumerate}

Dla przykładu powiedzmy, że chcemy stworzyć system w rodzaju chomikuj.pl, tzn. każdy może wrzucać pliki różnego rodzaju i rozmiaru, można też ``chomikować'' pliki znalezione u innych, więc żeby nie powielać dużych danych na serwerze graf będzie tu niezłym rozwiązaniem. Węzłami mogą być pliki i użytkownicy, krawędź dla uproszczenia może być jednego typu ``posiada plik''. Węzły zawierają pola klucz-wartość, np. {\it data dodania}, {\it opis} itp. no i przede wszystkim {\it zawartość} czyli coś jak kolumna BINARY w relacyjnych bazach. Wymagana jest duża skalowalność, więc baza musi być rozproszona, dlatego wybrane ``właściwości'' węzła mogą być przechowywane na służących do tego serwerach {\it storage}.

\section{Proponowana architektura}

\begin{figure}
 \includegraphics[width=18cm]{architektura.png}
 \caption{\label{arch}Proponowana architektura}
\end{figure}

Na rysunku \ref{arch} widać połączenia między serwerami. Użytkownik wysyła zapytanie do jednego z dwóch serwerów ``indeksowych'', przechowujących informacje o połączeniach między węzłami. Serwery indeksowe są na bieżąco synchronizowane i mają zawsze aktualną zawartość. W przypadku zapytań nie modyfikujących danych nie muszą się kontaktować, mogą być używane zamiennie, w razie modyfikacji jakiegoś węzła w ramach transakcji powinny zostać oba uaktualnione. Jeśli jeden z nich ulegnie awarii, baza do czasu jej usunięcia będzie w trybie tylko do odczytu.

Każdy uploadowany plik byłby równolegle zapisywany na {\bf dwóch} serwerach ``storage'' (ich łączna ilość be ograniczeń) w ramach jednej transakcji. Wybierane byłyby np. dwa aktywne serwery które mają najwięcej wolnego miejsca. Gdyby któraś z operacji się nie powiodła, transakcja jest przerywana z błędem, ewentualnie DBMS robi retry 1-2 razy.

Do napisania byłaby więc baza na te dwa serwery. Konfiguracja DNSa powinna być łatwa, ewentualnie można go sobie darować i zaszyć klientowi na sztywno adresy obu serwerów\footnote{Ale warto zwrócić uwagę na zamiłowanie dr K. do DNSów}. Serwery plików mogłyby być zwykłymi serwerami FTP, upload z Javy jest prosty.

Nie mam już dziś czasu, ale mam nadzieję że trochę uporządkowałem tę wizję. Wydaje mi się że w zupełności podpada pod definicję rozproszonej bazy danych, zapewnia też przezroczystość dla użytkownika (dla niego to system żądanie-odpowiedź), współbieżność (nic nie stoi na przeszkodzie), skalowalność (wystarczy dodawać nowe storage serwery bo one biorą na klatę największe obciążenie), tolerowanie awarii dowolnego węzła i dowolnego połączenia między dwoma węzłami (w bardzo szczególnym przypadku baza przechodzi w stan read-only na czas naprawy awarii).


\end{document}